An application platform may implement business objects to support different business solutions. A business object, for example, is a software model representing real-world items used during the transaction of business. A business object may comprise a SalesOrder object model or an Organization object model. Instances of these object models, in turn, represent specific data (e.g., SalesOrder SO435539, ACME corporation).
A business object may specify business logic and/or data having any suitable structure. The structure may be determined based on the requirements of a business scenario in which the instance is to be deployed. A business application for a particular business scenario may require many business object instances, where the structure of each has been determined based on the requirements of the particular business scenario.
A customer deploying a business solution may desire changes to a business object included in the business solution. For example, a customer may require a field (e.g., SerialNumber) which does not exist within the Product business object of a business solution. In addition, another customer may require an additional node or query within the Product business object of the same business solution.
Some conventional application platforms support the addition of extension fields to nodes of existing business objects. Consequently, these application platforms are able to store data associated with instances of these extension fields (e.g., Ser. No. 27/44,234) in a primary persistency (e.g., a relational database, flat files). This data can then be consumed by user interfaces, queries and other entities supported by the application platforms.
Known application platforms support indexed searching of business object data. Generally, these platforms replicate the business data within a secondary persistence. The data within the secondary persistence is indexed according to an index schema, and may be accessed via developer-created views on business object nodes. Views describe a search structure, result structure and semantically-relevant relationships (joins) between the involved nodes.
The application platform maintains synchronization between the primary persistency and the secondary persistency during operation. For example, an enterprise service manager may call an agent when saving business object data to the primary persistency. The agent then indexes the data directly into the secondary persistency.
It is often desirable to modify a view to include a newly-added extension field. This task presents difficulties. First, modification of a view to include a newly-added extension field relies of the existence of metadata (e.g., field type descriptions) describing the extension field. In this regard, addition of the extension field to the application platform results in the creation of associated metadata in a metadata repository of the application platform. The addition does not, however, result in generation of the metadata required for view modification.
Also, in order to add an extension field to a view, conventional systems require execution of an “initial load” into the secondary persistency. During an initial load, all data of all nodes within the primary persistence are retrieved, the index schema is rebuilt based on the data, and the data are stored in the secondary persistence according to the index schema. During execution of the initial load, no views or queries of the secondary persistency are able to return reliable data.
Moreover, data associated with an instance of the extension field can be produced and saved in a primary persistency after creation of the extension field. As described above, such saving may cause an enterprise service manager to call an agent so that the data of the associated business object instance may be synchronized with the secondary persistency. However, if no view on the extension field has been created, the schema of the secondary persistency is unaware of the extension field, and the data of the extension field is therefore not indexed within the secondary persistency.
Systems are desired to facilitate building of views on an added extension field without requiring an intervening initial load. Also desired is the ability to index data associated with an added extension field regardless of whether or not a view on the extension field exists.